1. Technical Field
The present invention generally relates to the resolution of Number Portability issues in origin when the calling subscriber belongs to a network based on the Internet Protocol (IP), and the called subscriber is a ported subscriber between Classical networks. More specifically, the calling subscriber belongs to a mobile system of a third generation and, for the purpose of the present invention, a Classical network may be a Public Land Mobile Network (PLMN) of a first or second generation, a Public Switched Telephone Network (PSTN), or an Intelligent Network (IN).
The current development of new mobile communication systems, aimed by the rapidly growth of Internet applications to incorporate new services, makes the interconnection of systems based on previous generations to newer systems be a must. For instance, a third generation mobile system (hereinafter simply referred to as 3G) like the Universal Mobile Telecommunication System (UMTS) has to fully inter-work with the existing mobile systems like GSM. In this respect, said UMTS supports and makes use of the Session Initiation Protocol (SIP) over the Internet Protocol (IP), whereas said GSM makes use of the Mobile Application Part (MAP) protocol over a Signalling System number 7 (SS7) protocol. This is an instance of interconnection of a 3G network to a classical PLMN network. Moreover, a full inter-working between 3G systems and Intelligent Networks (IN) must also be supported, the latter making use of the Intelligent Network Application Part (INAP) protocol over SS7. This is an instance of interconnection of a 3G network with a classical PSTN network.
The current trends and standards generally accepted for 3G networks propose a general purpose Domain Name Server (DNS) to solve the addressing by providing appropriate routing data. Originally, a Domain Name Server (DNS) was intended to provide an Internet address for a given Uniform Resource Locator (URL) included in the query from any client entity. A URL is a certain expression following specific and standard format rules that unambiguously identify a particular server or client. An interested reader is kindly referred to the current version of the “Internet Official Protocol Standards”, as well as to appropriate and related working groups of the Internet Engineering Task Forces (IETF).
According to the Request for Comments 1034 (RFC 1034), a domain name identifies a node. Each node has a set of resource information. All the resource information that is associated with a specific name consists of separate Domain Name Server Resource Records (DNS RR). At present, a particular DNS RR called Naming Authority Pointer (NAPTR) specifies rule expressions that applied to the received string produce either a new domain level or a Uniform Resource Identifier (URI) as result, accompanied by appropriate flags to unambiguously interpret such a result. Then, the entity having issued the query will make use of such a new domain level or URI, depending on the flag values, in eventual subsequent queries for NAPTR resource records (NAPTR RR), or as an output of the current process. Details and most of the relevant information with regard to encoding rules, formats and fields related to NAPTR RR can be found in the RFC 2915 of the Network Working Group of IETF organization.
In accordance with said RFC 2915 (and others mentioned per item below), and particularized for the purpose of the present invention, the format of the NAPTR RR comprises the following fields:                Domain: The domain name that this resource record refers to, and “key” for entry in the rule database.        TTL: Time to Live (DNS RR defined in RFC 1034).        Class: It usually takes the value “IN” standing for Internet (DNS RR defined in RFC 1034).        Type: The Type code for NAPTR is 35.        Order: A 16-bit unassigned integer specifying the order in which the NAPTR records must be processed to insure the correct ordering of rules.        Preference: A 16-bit unassigned integer specifying the order in which NAPTR records with equal “order” values should be processed, wherein low numbers are processed before high numbers.        Flags: A character-string used to unambiguously interpret the rest of fields in this resource record. At present, there are four flags, “S”, “A”, “U” and “P”, where the three former denote a terminal lookup. Further, the “U” flag denotes that the next step is not a DNS lookup but rather that there is a URI provided in the “regexp” field.        Service: The service may specify the service itself available through current analysis path or, depending on what the flag fields state, it may also specify the particular protocol to talk with the service.        Regexp: A string containing a substitution expression that applied to the original string is used to construct the next domain name lookup.        Replacement: It indicates the next NAME to query for NAPTR, or Server Location Resource Records (SRV RR), or address records depending on the value of the flag field. In accordance with the RFC 2782 said SRV RR is intended for several purposes. A first purpose is to allow administrators to make use of several servers for a single domain. Another purpose is to allow administrators to move services from one host to another host in an easier way. Still another purpose is to allow administrators to designate some hosts as primary servers for a service, and other hosts as secondary servers.Also in accordance with said RFC 2915, and particularized for the purpose of the present invention, the basic NAPTR algorithm behaves in such a manner that the meaning of the flags and services imply that the output of one rewrite path is a new key that points to another rule. This looping algorithm allows NAPTR records to specify a complete rule by linking or looping individual incremental rules.        
At present, the current trends for solving the addressing in 3G networks assume that an entity responsible for call control in an originating network issues a DNS query toward the corresponding network DNS. Provided that said DNS can resolve the addressing, the corresponding response is returned back to the querying entity responsible for call control. This feature does not offer major drawbacks to resolve addressing for a called subscriber at a classical network whose subscriber number belongs to series owned by his or her operator. However, and specially due to Number Portability support, said DNS could be unable to directly answer, but rather said DNS should submit such a query toward a General DNS on national premises. Said General DNS is supposed to provide addressing data of another DNS belonging to the destination network to which a subsequent query should be issued from the originating DNS. Under these assumptions, an especially relevant scenario turns up when the destination network is a classical network such as a conventional PLMN or PSTN network. Said classical networks nowadays do not comprise, or do not internally need, a DNS for addressing, but rather a more specific Number Portability Database (NPDB) not able to understand a DNS query. In this scenario, the General DNS above cannot provide a destination DNS of a classical network back to the originating DNS for the latter to issue the corresponding new query.
Currently, there is no apparent solution already implemented but, rather, there are several approaches still under discussion and herein described for the sake of clarity as presenting the objects of the present invention.
2. Description of the Related Art
At present, a DNS hierarchical structure is perfectly able to provide an URI indicating a target entity to route a call from the originating entity to a called subscriber whose subscriber number is within number series belonging to his or her operator at a classical network, as already stated. This well known feature can be easily derived from the teaching of Patent Application WO 97/31490, for instance. However, the introduction of Number Portability scenarios in both 3G and classical networks make this solution less feasible since the number series premises are not as valid as before. In this respect, individual entries for particular subscriber numbers, rather than series, have to be considered, at least, at a General DNS on national premises. On the other hand, a quite common scenario generally accepted is that the “donor” network should be responsible for maintaining the information related to the current network where own subscribers have been ported.
A quite simple solution is the introduction of a DNS in all the classical networks or, at least, in all the classical networks having ported subscribers. As shown in FIG. 1, when a 3G subscriber initiates a call [S-10] with a 3G user equipment (UE), the Proxy Call State Control Function (P-CSCF) forwards the SIP message [S-20] received from the UE toward the SIP server most likely via an Interrogating Call State Control Function (I-CSCF). Next, the I-DSCF forwards said SIP request [S-30] to a Serving Call State Control Function (S-CSCF) determined at a previous Registration procedure. Said Registration procedure is not significant at this step for the purpose of the present invention. At this point and in accordance with the 3G Technical Specification 23.228 version 5.0.0, the S-CSCF is supposed to obtain from a certain database the Address of the remote I-CSCF for the network operator serving the destination subscriber from the destination name of the terminating subscriber. This said certain database is currently assumed and mostly accepted as a DNS.
However, this remote I-CSCF of the destination network, whose address is requested from said certain database, does not make any sense for classical networks like a GSM network for instance. Assuming that there is no DNS in classical networks, the fact of supporting Number Portability implies that the current classical network where the terminating subscriber holds his or her subscription cannot be simply derived or solved at said certain database by performing the analysis on subscriber number series premises. Further, given that subscriber number series premises can not be applied for analysis said certain database should contain a huge amount of subscriber names and analysis paths to solve addressing what is close to unfeasible.
The assumption presented in FIG. 1 is that a DNS entity is introduced in these classical networks, the latter behaving as “Donor” networks, namely networks with subscribers ported to other classical network operator. Thereby, said certain database toward which the S-CSCF issues the query [S-40] is a DNS belonging to the originating network [hereinafter referred to as O-DNS]. Given that the destination subscriber does not belong to the originating 3G network, O-DNS submit the query [S-41] to a General DNS on national premises [hereinafter referred to as G-DNS]. Said G-DNS resolves the addressing and returns back [S-42] the address of a DNS belonging to the destination network [hereinafter referred to as D-DNS]. The O-DNS then submits the query [S-43] toward said D-DNS. Notice that a common provisioning of number portability data have to be carried out to both NPDB and said D-DNS at the destination classical network. This common provisioning could be implemented by a clustering between the NPDB and the D-DNS, wherein both serial and broadcast clustering are possible. This D-DNS eventually resolves the addressing returning back [S-44] a valid Routing Number to directly access, without further querying, the natural entry point to the new destination network, that is, the “recipient” network where the destination subscriber was ported. At reception of this Routing Number, the O-DNS returns back [S-45] to the querying S-CSCF said Routing Number to access the current network where the destination subscriber holds his or her subscription. Different and equivalent approaches may turn up at this step without substantial differences to access the destination network. The assumption presented in FIG. 1 is that the S-CSCF routes the call toward a Breakout Media Gateway Controller (BMGC) including the received Routing Number so that said BMGC can appropriately determine which PLMN or PSTN Gateway must be addressed. At present, some trends suggest that said BMGC should comprise a Breakout Gateway Control Function (BGCF) and a Media Gateway Control Function (MGCF), possibly as separate entities. However, for the purpose of the present invention this is not relevant and they both, BGCF and MGCF, can be considered as a unique entity, BMGC, supporting SIP to and from the 3G network, and ISUP to and from classical networks. When the call is received in the BMGC, the destination PLMN or PSTN Gateway is determined from the received Routing Number. Then, the SIP INVITE message received [S-50] at the BMGC from the 3G network is processed to prepare accordingly an ISUP IAM message [S-60] in order to transfer the call to the recipient classical network where the destination subscriber is ported.
The assumption presented in FIG. 1 is that the call is routed [S-60] from said BMGC to the corresponding Gateway Mobile Switching Center (GMSC) of a classical PLMN in accordance with addressing data previously obtained from the D-DNS for the destination ported subscriber. The call received at the GMSC progress from now on in the normal and well-known way. That is, the GMSC requests [S-70] routing data for the ported subscriber to the Number Portability Database (NPDB) of this recipient network and the query is submitted [S-72] to the Home Location Register (HLR) in charge of such subscriber. Then, the HLR requests a Roaming Number [S-74] to the coupled entity Mobile Switching Center and Visitor Location Register (MSC/VLR) where the subscriber is currently roaming, which returns back [S-76] to the HLR said roaming number. The HLR sends [S-78] the received roaming number to the GMSC, which can now route the call [S-80] to the appropriate MSCNLR, and from there toward [S-90] the Base Station System (BSC/BTS) and to the destination subscriber terminal [S-95].
This solution may solve the number portability procedure though such a solution is essentially based on introducing a DNS in all classical networks from where subscribers have been ported, what represents a quite significant drawback for the corresponding classical network operators. These classical network operators, apart from losing subscribers, should even buy, administer and operate DNS entities only to help 3G network operators. Moreover, said new DNS to be incorporated to classical networks must be closely coupled to the traditional NPDB in said classical networks with a common provisioning of Number Portability data. This Common provisioning solution might consist of a Mediation Device between the Customer Administration Service (CAS) and the Network Elements, namely the nodes that are going to be provisioned. This Mediation Device is responsible for the provision of the same number portability data to both NPDB and DNS nodes. For this purpose, a Network Cluster, defined as a number of network elements holding the same subscriber data, composed of a DNS and a NPDB is needed. This Network Cluster is only required for exclusively number portability data. Requests are distributed to the Network Elements in the cluster according to a Clustering Strategy. The Clustering Strategies can be mainly of two types: Serial Provisioning and Broadcast. In Serial Provisioning one Network Element is configured as primary and the other as redundant; therefore the Mediation Device sends the service order first to the primary, and waits for a response code. Afterwards, it will send the service order to the secondary. On the other hand, in Broadcast strategy the same command is sent to all the Network Elements in the cluster at the same time.
Notice that this and other equivalent or similar solutions would be necessary for a classical network operator supporting Number Portability in order to introduce a DNS to help 3G network operators, rather than due to classical network needs.
To overcome this and other drawbacks, derived from introducing a DNS in all classical networks to help 3G networks to solve in origin the Number Portability, is one of the objects of the present invention.
In this respect, another solution to solve Number Portability in origin in 3G networks, without forcing classical networks to include a DNS, proposes to carry out the breakdown between 3G and classical networks in the 3G terminals. That is, these terminals should be able to support 3G and Classical Services capabilities. Moreover, 3G networks must have a classical network infrastructure to handle new calls once the terminal switches from 3G to classical service capabilities. As shown in FIG. 2, when a 3G subscriber initiates a call [S-10] with a 3G user equipment (UE), the P-CSCF forwards the SIP message [S-20] toward the SIP server likely via an I-CSCF. Next, the I-CSCF forward said SIP request [S-30] to the S-CSCF. The S-CSCF issues a DNS query [S-40] to the O-DNS. Given that the destination subscriber does not belong to the originating 3G network, O-DNS submits the query [S-41] to the G-DNS on national premises. So far, this solution looks like the previous one; however, the assumption is now that the G-DNS can not resolve the requested addressing query for a classical network entity. Said G-DNS returns back [S-42] an unsuccessful result to the querying entity, the O-DNS, which in turn generates another query response accordingly and sends it back [S-45] to the S-CSCF. At receipt of the query response, the S-CSCF generates a SIP REDIRECT message to simply return such unsuccessful result [S-35] back to the I-CSCF which transfers [S-25] such message and result back to the P-CSCF, and from the latter an appropriate unsuccessful result is submitted [S-15] to the 3G UE. This solution basically proposes that said 3G UE performs the call breakdown toward the classical network. Consequently, all the process following the breakdown is absolutely in accordance with the current behavior of such classical networks, for example PLMN or PSTN.
For instance, the assumption in FIG. 2 is that the 3G operator also has infrastructure for a conventional PLMN, and that the call has to be routed toward a classical “recipient” network C via the “donor” network B.
As presented in FIG. 2, the process followed to route the call from the originating network A to the “donor” network B [S-12, S-22, S-32, S-62] is absolutely in accordance with the current behavior of a traditional GSM system in a scenario where number portability is supported. Similarly, the process followed to route the call from the “donor” network B to the “recipient” network C [S-71, S-73, S-63] is also in accordance with said behavior of GSM systems. And eventually, the process to route a call received at a “recipient” classical network for a ported subscriber to reach the corresponding subscriber terminal [S-70, S-72, S-74, S-76, S-78, S-80, S-90, S-95] is also in accordance with said behavior of GSM systems.
This solution, compared to the previous one, offers the advantage of not imposing the introduction of DNS entities in classical networks. However, it still presents the clear drawback of introducing dependencies on the 3G UE that 3G operators and subscribers have to respectively support and make use of.
It is an object of the present invention to overcome these dependencies from the 3G user equipment. That is, it is an object of the present invention to offer a solution that gives freedom to terminal suppliers in order to implement said terminals with or without support for classical network capabilities. Besides, it is an object of the present invention to offer a solution that gives freedom to the 3G subscribers to choose their own 3G terminal without unnecessary constraints. Moreover, it is an object of the present invention to offer a solution that gives freedom to the 3G operators to support services and subscriptions without unnecessary constraints derived from dependencies on user equipment.
Furthermore, these objects of the present invention are achieved accordingly with the aforementioned object of the present invention to offer a solution that does not impose the introduction of DNS entities in classical networks in order to help 3G networks to solve in origin number portability issues.